[P1] Make version-ID uniqueness database-enforced

Could we make this uniqueness check database-enforced? The SELECT and later INSERT are not atomic. On OceanBase, two transactions can both observe no row and insert the same entry_version_id for different memory_artifact_id values, because the current primary key and unique constraints include the Memory ID. Both commits can therefore succeed, leaving an ID that this code treats as scope-global duplicated. Please add a database-level UNIQUE (scope_id, entry_version_id) with an explicit migration for existing tables, translate the resulting integrity error, and cover it with a coordinated two-connection race where both reads complete before either insert.

Thank you for catching this. I reproduced the two-transaction gap and confirmed that the SELECT/INSERT check was not sufficient. This is now fixed with a database-enforced unique index on (scope_id, entry_version_id), startup migrations for existing SQLite and OceanBase tables with duplicate-data detection, IntegrityError translation with rollback, and a coordinated opt-in OceanBase two-connection regression test.

[P1] Validate history already referenced by the base

This only collects predecessors for value.entry_versions, so an invalid version already referenced by canonical_base is never rechecked. I reproduced this by changing a persisted v1 row to previous_version_id="does-not-exist" and then appending an unrelated entry: the commit succeeds and the new Revision still references the broken history. Because older releases could already persist this state, please either validate the base-referenced chain here or provide a one-time audit/migration plus database constraints that make this assumption safe.

Thank you for the detailed reproducer. I verified that an unrelated append could carry forward a broken predecessor already referenced by the canonical base. This is now fixed: the commit boundary validates every base-referenced chain back to v1, including identity, version sequence, predecessor links, revision ordering, and canonical hashes. A regression test covers corruption in a deeper ancestor.

[P2] Reject semantic revisions of inactive entries

This accepts a revise whenever the state is unchanged, including inactive -> inactive. A direct SPI writer can therefore deactivate an entry containing “black tea” and commit an inactive revision containing “green tea”, although the Memory contract requires reactivation before a semantic revision. organize(normalize) still needs a narrow exception, so please allow an inactive revision only when the new and predecessor canonical content bytes are identical and the change is normalization; otherwise require reactivation first.

Thank you for pointing this out. I reproduced an inactive semantic revision and confirmed that it violated RFC 0014. This is now fixed: inactive revisions are rejected unless they are the narrow organize(normalize) case and the predecessor/new canonical content bytes are identical. Both the rejection and the allowed normalization path are covered by regression tests.

[P1] 不要用精确浮点相等判断单位向量已经规范化

MemoryService._embed_texts() 已先执行一次 canonical_embedding()；这里再次归一化后再做 tuple 精确比较。单位归一化不是位级幂等的：公开 MemoryService.remember() 探针让模型返回 (0.2407121489724894, -0.9705965492093231)，服务层得到 (0.24071214897248938, -0.9705965492093231)，这里二次归一化又把首项改成 0.24071214897248935，于是合法的有限非零向量被抛为 _InvalidMemoryCommitError("vector")，整个 Memory 写入失败。现有向量测试只使用 (1, 0, 0) 这类轴向量，无法覆盖该舍入路径。请改为校验维度、有限性和带容差的单位范数（或确保只规范化一次并复用结果），并补一个非轴向量的公开 MemoryService.remember() 回归测试。

感谢指正。我使用你给出的非轴向量复现并确认了这个问题：二次归一化后的精确浮点比较确实会误拒绝合法写入。现已修复为校验维度、有限性和带容差的单位范数，同时保留 profile/content hash 校验，并补充了公开 MemoryService.remember() 稠密向量回归测试及非单位向量拒绝测试。